Project: Infra-Red control
By David Empson
Copyright (c) 1994 Apple Users' Group, Sydney
Republished from Applecations, a publication of the Apple Users' Group, Sydney, Australia.

dempson@actrix.gen.nz
P.O. Box 27-103, Wellington, New Zealand
Source: Internet comp.sys.apple2

Controlling appliances using Infra-Red (IR) signals seems to be one of the more popular hardware projects that people interface with computers. I've had a number of successes with this: I can control my stereo, video and TV from the computer, as long as my IR transmitter is pointing in the right direction.

I've made up my own transmitter and receiver circuits on veroboard. They communicate with the computer via the joystick port using one of the button inputs (for the receiver) and an annunciator (the transmitter).

The receiver is not amplified, so it is only suitable for short-range sampling of commands from a remote control (which is what I wanted it for). I many eventually put a long range receiver on it as well.

IR signals are typically based on a 36 to 40 kHz pulse train, which is modulated (switched on and off) by a control signal.

Some receivers have a narrow frequency response, and will ignore commands which aren't using the right pulse frequency.

My TV and Stereo are both made by Sony. Sony equipment uses a 40 kHz carrier, and a common command set for all devices: a twelve bit code, without error correction. The last five bits are a device code and the first seven are a command number. The distinction is blurred somewhat with stereos - mine responds to commands in about five different device code ranges.

(Side note: On occasions, I've managed to accidentally trigger my TV with my stereo's remote control, if it is pointing in a different direction. The TV channel selection commands use very similar codes to the CD player track selections, and the lack of error detection means that the TV thinks it saw a command for it.)

My video is a Panasonic J11. It uses a huge number of bits (something like 50) in each command, and some commands are variable length. I haven't worked out how the programming command works - I think there is a bi-directional protocol in use.

Older Panasonic and National devices use a different command set, which has a series of bits then the same bits
transmitted in reverse order (for error detection). I can't recall off-hand how many bits are used.

The method used to encode the bits varies widely. In the Sony system, there is a fixed gap between each data bit, and the width of the "on" period varies according to whether it is a zero or one bit. I have notes on the Panasonic system somewhere, but I haven't done as much work with it. The video has developed a fault in its IR receiver recently, which puts a damper on my experiments.

Recording IR commands could done by sampling the signal with a computer directly. However, hardware is needed because of the difficulty inherent with sampling the wave fast enough. If you are trying to deal with the 40 kHz carrier (or thereabouts) in software, you will probably be out of luck. You would have to be sampling at at least 80,000 samples per second to accurately record the waveform, or even higher if you don't know the exact carrier frequency (unless your VCR isn't too fussy).

That gives you 12.5 microseconds or less to sample a digital input and store the value somewhere.

You can't do this with a normal assembly loop on the Apple II - an absolute LDA and an indexed STA will take at least 9 cycles, and you still need an INX and BNE; 14 cycles for the whole loop. This would only give you 256 samples, and is too slow to accurately read the signal.

You could improve the speed and number of samples by unrolling the loop and storing in parallel to several pages of memory but this method gains more problems than it solves.

Using external hardware to filter out and generate the carrier, I can use a much more straightforward sampling technique. I use a loop which reads 8 samples into the accumulator (shifting bits in), then stores that in a large table. This is on an Apple IIgs, so I can take advantage of 16-bit index registers and get a very big table. A post-processing pass then counts the number of consecutive "1" or "0" bits and an analysis pass (specific to the type of remote) works out what bit pattern this represents.

It also means that I can test command codes by typing in arbitrary 12-bit codes. I found several commands that my stereo didn't have buttons for by using this technique (e.g. my CD player supports index cue and review, even though it has no display to indicate the index number).

For my transmitter, a friend built me a 40 kHz square wave generator (using a 4 MHz crystal and dividing by 100). This goes through an AND gate which is controlled by the
annunciator. When the computer turns on the annunciator, the IR pulses are transmitted. With the annunciator off, the IR pulses stop. This signal then goes to a series of IR LEDs, via a transistor.

On the receiver, I have a filter which eliminates the 40 kHz component, and produces a square wave (slightly delayed) which is high while the carrier is present, and low while the carrier is absent. This is basically the same signal used to control the transmitter.

I have a program in the computer which samples this input as fast as it can, then analyses it to locate and decode and the IR command sequence. I use a different program to decode each remote.

For the Sony remote, this results in a 12-bit number, and I've kept a list of these. I have several programs which can transmit these codes back to the stereo or TV: a small machine language routine is used by a couple of BASIC programs to control either device. One program provides a menu of all of the commands supported by my stereo. The other lets me type in 12-bit command codes to try out.

I also have a HyperCard IIgs XCMD which can transmit Sony commands, and I've written a stack which has all of the remote control buttons spread over several cards. One of the cards even has a text field which lets me type in a track number, and the stack works out which commands need to be sent to the CD player to get it to select that track.

If you can find back issues of BYTE magazine, there were a couple of very good articles about IR remote controls (analysing how they work, and building a remote control and a learning remote). This was in the February and March 1987 issues, in Steve Ciarcia's Circuit Cellar column.

[Sub-editor's note: David is trying to send me circuit diagrams for the receiver and transmitter. If he does they will appear next month.]

THIS CONTENT COPYRIGHT © 2007, APPLE MACINTOSH USERS' GROUP, SYDNEY
Permission has been obtained to make this material available on the Internet.

Permission is hereby granted for non-profit user groups to republish this content.
PLEASE CREDIT THE AUTHOR AND THE SOURCE: Applecations, publication of the Apple Users' Group, Sydney, Australia

THIS PAGE COPYRIGHT © 2007, ANDREW ROUGHAN